An Agile Approach to a Legacy System
I recently read an interesting paper, "An Agile Approach to a Legacy System"[1], on how to migrate legacy systems. One statement resonated with me:
The drive for the original rewrite came from development management and developers not business and users.
I have been involved in two major refactoring which was initiated by Engineers. One barely successful and the other a semi failure. It is easy to get excited about a rewrite to improve performance or because the code is messy to deal with. One hardly thinks about the business use case for such.
The author describes how and why they approached migrating a legacy system and what should be the motivation for such. In the narration he provided a few rule of thumbs that were interesting. I have listed them below for convenience:
- Don't reproduce legacy code
- Always ask the users what the problem is
- Refactor a legacy application by delivering new business value
- Incrementally build trust - prove that you can do the hardest part of the system.
- Build a small, self-selected team
- Don't get hung up on process
- Involve the whole team with larger refactorings so that the team can move on as quickly as possible
- Effective teams need break points
- Treat politics as a user requirement
- A System that connects to a legacy system must be tested using live feeds
- Engage users and they not only won't they turn it off, they will fight some of your battles for you
- Keep giving a good team motivated by giving them new hard problems - don't waste a good team
A few things like "Treat politics as a user requirement" is thought provoking. But other things like "Don't get hung up on process" and "Build a small, self-selected team" resonates to what others have said.
I would recommend reading it even if you don't have to rewrite legacy systems. A very short read and full of wisdom.
